某壳分析+修复（二）

声明

仅限技术讨论，不得用于非法途径，后果自负。

分析中有什么错误欢迎大家指出

Java层分析

快分析完才想起打算用art模式分析的，那就分析下一个壳用art模式分析吧。

这个是dalvik模式，nexus5 4.4.4

逻辑比较简单，主要是加载libSecShell.so，和替换原APP的Application,Helper.h的native方法是对华为手机一些设置，手里没有华为手机具体native没有分析

java层有一个DexInstall类，Native层会通过jni方法调用install(ClassLoader loader, String dex_path, String dexDir)方法

一直往下分析，此方法主要作用就是把Native层解密的dex通过反射调用makeDexElements方法把生成的Element数组加入到dexElements数组中

具体过程可以参考android源码

• https://www.androidos.net.cn/android/4.4.4_r1/xref/libcore/dalvik/src/main/java/dalvik/system/BaseDexClassLoader.java
  

• https://www.androidos.net.cn/android/4.4.4_r1/xref/libcore/dalvik/src/main/java/dalvik/system/DexPathList.java
  

Native方法分析

通过查看.init_array和.finit_array段没有做具体内容，解密方法应该放在了JNI_OnLoad中，一看就是经过llvm混淆过，正常代码怎么会有这种逻辑

f5看一眼，能正常反编译，大体扫一眼逻辑还是可以接受的没那么变态，发现字符串都被加密了，部分方法也被加密了

只能动态分析了，具体就不帖代码了，最后我会把分析的so文件分享给大家

JNI_OnLoad 4.4.4 dalvik 流程，这里的反调试并不影响我们分析这个，反调试具体代码我没有分析，感兴趣的可以分析一遍

Jar解密方法，有兴趣的可以还原下，那样直接把apk的jar解密直接解压就是原apk的dex文件

脱壳dump

壳只是把原dex加密放到了secData0.jar中，所以直接拿到dex，修复AndroidManifest的application重打包完美运行

dump方法比较多，列举几个方法

1.通过还原加密算法，解密secData0.jar，直接解压解密jar就是原dex（不推荐这种方法，虽然方便，但算法更新太快）

2.壳保存在.cache的classes.dex是加密的，主要通过hook实现，打开时解密，关闭时候加密。

壳hook了open和mmap方法，这里下断得到的dex是解密的dex即原dex（调用open，mmap方法可能不只是打开dex，通过文件大小可以筛选出来）

3.在解密jar函数下断点，执行完得到解密jar，dump出解密jar，解压出dex

4.壳hook了dvmRawDexFileOpen，在这里下断点，得到的dex是解密的dex即原dex（比较推荐这种）

提醒

1. idb用的ida7.0保存的

2. 给switch下断点注意，一级下的switch，如果没执行到一级的switch直接下断点可能会失败（不知道是ida问题还是？）

总结

别被JNI_OnLoad的流程给唬住，静下心来分析还是挺简单的。

感觉这种内存加载dex安全性还是挺低的，只要分析出关键代码dump出原dex那就是分分钟的事，连修复都不用。

本文由看雪论坛 Roselia  原创

转载请注明来自看雪社区

往期热门阅读：

扫描二维码关注我们，更多干货等你来拿！